Printed: Apr 30, 2025
From: http://www.jcp.org/en/jsr/detail?id=166
|
Specification Leads | |||
Doug Lea | Lea, Doug | ||
![]() |
|||
Expert Group | |||
Bowbeer, Joseph | Goetz, Brian | Google Inc. | |
Holmes, David | Lea, Doug | Peierls, Tim | |
SAP SE | Sun Microsystems, Inc. |
Updates to the Original Java Specification Request (JSR)
For additional information, sample draft APIs, and access to an interest-group mailing list for JSR-166, go to http://gee.cs.oswego.edu/dl/concurrency-interest/
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification
Submitting Member: Doug Lea
Name of Contact Person: Doug Lea
E-Mail Address: dl@cs.oswego.edu
Telephone Number: +1 315 312 2688
Fax Number: +1 315 312 5424
Specification Lead: Doug Lea
E-Mail Address: dl@cs.oswego.edu
Telephone Number: +1 315 312 2688
Fax Number: +1 315 312 5424
Initial Expert Group Membership:
Joshua Bloch, Sun
Sam Midkiff, IBM
David Holmes
Joseph Bowbeer
Tim Peierls
Supporting this JSR:
Sun
Section 2: Request
This JSR has aims analogous to those of the JDK1.2 Collections package:
1. To standardize a simple, extensible framework that organizes commonly used utilities into a small enough package to be readily learnable by users and maintainable by developers.
2. To provide some high-quality implementations.
The package will consist of interfaces and classes that tend to
be useful across diverse programming styles and applications.
These classes include:
Atomic variables.
Special-purpose locks, barriers, semaphores and condition variables.
Queues and related collections designed for multithreaded use.
Thread pools and custom execution frameworks.
We will also examine related support in the core language and libraries.
Note that these are entirely distinct from transactional concurrency control frameworks used in J2EE. (However, they will be useful to those creating such frameworks.)
J2SE
Low level threading primitives, such as synchronized blocks, Object.wait and Object.notify, are insufficient for many programming tasks. As a result, application programmers are often forced to implement their own higher level concurrency facilities. This results in enormous duplication of effort. Further, such facilities are notoriously hard to get right and even more difficult to optimize. The concurrency facilities written by application programmers are often incorrect or inefficient. Offering a standard set of concurrency utilities will ease the task of writing a wide variety of multithreaded applications and generally improve the quality of the applications that use them.
Currently, developers can use only the concurrency control constructs provided in the Java language itself. These are too low level for some applications, and are incomplete for others.
The vast majority of the package will be implemented on top of lower-level Java constructs. However, there are a few critical JVM/language enhancements surrounding atomicity and monitors necessary to obtain efficient and correct semantics.
java.util.concurrent
Only indirectly, in that JVMs running on different platforms may be able to differently optimize some constructions.
No
No
No
The goal is to include this specification in the J2SE 1.5 (Tiger) umbrella JSR.
E-mail, teleconferences, and infrequent meetings. We will also use or create an open mailing list for discussions by other interested people outside the expert group.
Section 3: Contributions
Doug Lea's package, available at
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
This package has been available for over three years, which has resulted in usage experience that will be exploited in defining this standardized package.
Others similar packages include:
The JHPC package: http://sourceforge.net/projects/jhpc
JThreadKit: http://www.jthreadkit.com/
It is likely that some of the classes and interfaces will be similar to those in Lea's package. The initial members have already begun creating draft specifications.
Section 4: Additional Information (Optional)
None